home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-tn3270e-luname-print-00.txt < prev    next >
Text File  |  1993-07-28  |  26KB  |  699 lines
  1.  
  2.  
  3. TN3270 Enhancements Working Group                            C. Graves
  4. Internet Draft                                    Open Connect Systems
  5.                                                              July 1993
  6.  
  7.  
  8.  
  9.  
  10.              TN3270 Extensions for LUname and Printer Selection
  11.  
  12.       i.   Status of this Memo
  13.  
  14.       This document is an Internet Draft.  Internet Drafts are working
  15.       documents of the Internet Engineering Task Force(IETF), its
  16.       Areas, and its Working Groups.  Note that other groups may also
  17.       distribute working documents as Internet Drafts.  Internet Drafts
  18.       are draft documents valid for a maximum of six months.  Internet
  19.       Drafts may be updated, replaced, or obsoleted by other documents
  20.       at any time.  It is not appropriate to use Internet Drafts as
  21.       reference material or to cite them other than as a "working draft" 
  22.       or "work in progress."  Please check the I-D abstract listing 
  23.       contained in each Internet Draft directory to learn the current 
  24.       status of this or any other Internet Draft.
  25.  
  26.  
  27.       ii.  Abstract
  28.  
  29.  
  30.       This document describes protocol extensions to TN3270.  There are
  31.       two extensions outlined in this document.  The first defines a
  32.       way by which a TN3270 client can request a specific device
  33.       (LUname) from a TN3270 server.  The second extension specifies
  34.       how a TN3270 printer device can be requested by a TN3270 client
  35.       and the manner in which the 3270 printer status information can
  36.       be sent to the TN3270 server.  Discussions and suggestions for
  37.       improvements to these enhancements should be sent to the TN3270E
  38.       Working Group mailing list TN3270E@list.nih.gov . These
  39.       extensions will be called TN3287 in this document.  This
  40.       information is being provided to members of the Internet
  41.       community that want to support the 3287 data stream within the
  42.       TELNET protocol.  The distribution of this memo is unlimited.
  43.  
  44.  
  45.       1. INTRODUCTION
  46.  
  47.       The need to communicate with IBM mainframe systems has a number
  48.       of unique requirements associated with it.  This document
  49.       addresses those needs in a TCP/IP communications network.
  50.  
  51.       IBM terminals are generically referred to as 3270's which
  52.       includes a broad range of terminals and devices,not all of which
  53.       actually begin with the numbers 327x.
  54.  
  55.       The 3270 family of terminals and the IBM mainframe applications
  56.       systems are VERY closely coupled and it is the nature of the way
  57.       the 3270s and the applications interact which require that this
  58.       document be available to provide a consistent way for the TCP/IP
  59.       environment to interact effectively with the 3270 applications of
  60.       the IBM mainframe world.
  61.  
  62. C. Graves                Expires January 1994                 [Page 1]
  63.  
  64.  
  65. Internet Draft           TN3270 Extensions                   July 1993
  66.  
  67.  
  68.       IBM mainframe applications systems have existed for almost two
  69.       decades now and are used to serve tens of thousands of users
  70.       daily.  For this reason it is usually the need of a mainframe
  71.       environment to add TCP/IP network support WITHOUT writing new
  72.       applications to run with the TCP network.  The TN3270 series of
  73.       documents addresses how this can be done and maintain
  74.       compatibility with those mainframe application systems.
  75.  
  76.       One of the unique characteristics of the 3270 terminals is their
  77.       ability to communicate status information in an out-of-band data
  78.       flow.  These status's are in turn used by the applications
  79.       systems to support error recovery, and conflict resolutions,
  80.       examples of these are printer out of paper, and terminal powered
  81.       up.  The terminals are also half duplex and block mode in their
  82.       operations.  Which results in the need to communicate when blocks
  83.       are being sent and when they end , and when they can not be sent.
  84.       This document describes these characteristics in IBM VTAM/SNA
  85.       terms.  Some VM mainframe application systems do not use VTAM,
  86.       so for those systems these terms don't apply.  For any systems
  87.       which use VTAM these terms apply and are dealt with in some way
  88.       by the TCP/IP to VTAM interface.
  89.  
  90.       VTAM/SNA is a hierarchical network and some of that hierarchy
  91.       needs to be addressed by the TCP network attaching to it., if the
  92.       applications systems are to continue to provide the same
  93.       applications support that they have provided to the 3270
  94.       terminals.
  95.  
  96.       The 3270 terminal environment consists of a terminal controller
  97.       with terminals attached to that controller.  In VTAM/SNA this
  98.       controller is called a PU (Physical Unit) and the terminals
  99.       called LUs (Logical Units).  The PU is used to communicate
  100.       management information to the VTAM/SNA system, and the LU is used
  101.       by the application to communicate with the terminal.  VTAM/SNA
  102.       identifies each LU and PU in a network by a unique name.  These
  103.       names are referred to as LUnames and PUnames, and is how the
  104.       network is managed and the applications identify what terminals
  105.       are being communicated with in the network.  The actual
  106.       connection between a terminal and the applications is referred to
  107.       as a session, and it is this session which has both in-band and
  108.       out-of-band information flows sent between the applications and
  109.       the terminals.
  110.  
  111.       VTAM/SNA 3270 terminals actually have two sessions when
  112.       communicating with the applications.  One session is directly
  113.       connected with the application and the other session is connected
  114.       directly to VTAM.  It is the session with VTAM, also called the
  115.       SSCP, that is used to communicate the out-of-band information
  116.       flows.  This session is called the SSCP-LU session, and the
  117.       session with the application is called the LU-LU session (in VTAM
  118.       an applications is just another Logical Unit).
  119.  
  120. C. Graves                Expires January 1994                 [Page 2]
  121.  
  122.  
  123. Internet Draft           TN3270 Extensions                   July 1993
  124.  
  125.  
  126.       One such out-of-band flow is the LUSTAT message with tells the
  127.       application that the status of the terminal has changed, and is
  128.       how a printer or screen tells the application that is ready, or
  129.       not ready to receive data.
  130.  
  131.       There are also flows which must be able to flow in the LU-LU
  132.       session, to help control the use of the terminal by applications.
  133.       The block of information sent in a session is called an RU
  134.       (Request Unit) and it tells what type of data this block
  135.       contains, how long it is and if more data (RUs) is coming along.
  136.       This is a gross over simplification of what RUs are and do, but
  137.       it should help understand their use in the TN3270 documents.
  138.       Some of the VTAM/SNA terms used to describe what an RU is
  139.       requesting are:  Chains/chaining which tell a session partner
  140.       that another RU is being sent or not being sent in this
  141.       transmission.  Brackets which are used to indicate that unit of
  142.       work is complete, such as when a printout of a file is complete.
  143.  
  144.       The determination of what of the VTAM/SNA protocols such as
  145.       brackets and chaining are to be used are managed by VTAM tables
  146.       called LOGMODE tables.  These tables are selected when an LU-LU
  147.       session is started and setup such things as bracket, and/or
  148.       chaining protocols, and the type of terminal data contained in
  149.       the RUs, such as printer data without screen formatting data (LU
  150.       type 1), 3270 screen formatted data (LU type 2) and 3270 screen
  151.       formatted data for a printer (LU type 3).  The LOGMODE tables
  152.       also contain the size of the RU to be sent and received.  These
  153.       tables also communicate the screen size of 3270 terminals such as
  154.       24X80 (Model 2), 27X132 (Model 5), etc.  Each LU has a LOGMODE
  155.       table entry hard assigned to it as part of the VTAM configuration
  156.       (often called a GEN).  The selection of these table entries can't
  157.       be controlled by the terminal (LU), or PU.  Rather they can only
  158.       be selected by the User at connection/logon time, or by the
  159.       application when the connection is established.  The actual
  160.       LOGMODE entries to be used during a session are sent at session
  161.       logon time, in a special type of RU called a BIND.  Once the bind
  162.       has been sent then the rules for the use of the session have been
  163.       set, can't be changed, and must be followed.
  164.  
  165.       The purpose of the TN3287 protocol is to provide a general IBM
  166.       3270 host printer communications facility.  Its primary goal is
  167.       to allow a method of connecting printer devices and printer-
  168.       oriented processes to each other.  This protocol will allow a
  169.       TN3270 Client to process 3287 print data streams.
  170.  
  171.       This memo supplements and extends the RFC 854, TELNET Protocol
  172.       Specification.  This memo also presents an example of the correct
  173.       implementation.
  174.  
  175.  
  176. C. Graves                Expires January 1994                 [Page 3]
  177.  
  178.  
  179. Internet Draft           TN3270 Extensions                   July 1993
  180.  
  181.  
  182.       2. GENERAL CONSIDERATIONS
  183.  
  184.       A TELNET connection is a Transmission Control Protocol (TCP)
  185.       connection used to transmit data with interspersed TELNET control
  186.       information.
  187.  
  188.       The companion document, RFC 854 -- "TELNET Protocol
  189.       Specification" should be consulted for further information about
  190.       the TELNET command, codes and code sequences referenced in this
  191.       specification.
  192.  
  193.  
  194.       3. CLIENT-SERVER NEGOTIATION
  195.  
  196.       The TN3270 Client and Server require a specific negotiation
  197.       protocol.  After the negotiation is complete, all transmission
  198.       between the Client and Server is in TELNET Binary format with a
  199.       TELNET "End-Of-Record(EOR)" sequence at the end of each data
  200.       stream.
  201.  
  202.       Support for the TN3287 data stream requires that both sides:
  203.  
  204.       A.  Are able to exchange binary data.
  205.  
  206.       B. Can establish the agreement between client and server on the
  207.       terminal type that will be used.
  208.  
  209.  
  210.       C. Agree to use the TELNET IAC EOR as a delimiter for inbound and
  211.       outbound TN3287 data streams
  212.  
  213.       This implementation requires the options: TERMINAL-TYPE and
  214.       BINARY be successfully negotiated between the Client and Server
  215.       before processing of any print data streams.
  216.  
  217.       This implementation supports host applications that can mix LU 1
  218.       and LU 3 type data in the data stream.
  219.  
  220.  
  221.       3.1  TN3287 SERVER
  222.  
  223.       The maximum Request Unit (RU) size is server specific, but should
  224.       not exceed 4 kilobytes.
  225.  
  226.       The LU type is determined by the bind from the mainframe
  227.       application.  The server, when bound, must remember LU 1 or LU 3
  228.       type.
  229.  
  230.       The server will automatically unbind the session upon receipt of
  231.       a TELNET CLOSE command.  The printer will be reported to VTAM as
  232.       powered down until a new TELNET connection is established.
  233.  
  234. C. Graves                Expires January 1994                 [Page 4]
  235.  
  236.  
  237. Internet Draft           TN3270 Extensions                   July 1993
  238.  
  239.  
  240.       3.2  TN3287 CLIENT
  241.  
  242.       The TN3287 Client is a TN3270 client created specifically to
  243.       print mainframe 3270 print data.  The client emulates the IBM
  244.       device type that it identifies itself to the TN3270 server as, in
  245.       this case, an IBM 3287 model 1 type printer.  The design of this
  246.       printer protocol is aligned with the way printing occurs in the
  247.       IBM host and how 3270 printers function.  These printer
  248.       extensions DO NOT support a 3270 printer client that cannot
  249.       accept both types LU 1 and LU 3 printer streams.  No IBM printer
  250.       operates in this fashion, and as a result, no TN3270 server could
  251.       function properly with mainframe applications if it didn't allow
  252.       for a mixing of LU 1 and LU 3 data streams.  The common way in
  253.       which this can occur is printer sharing between multiple IBM host
  254.       applications, such as CICS and JES.  Since there is no
  255.       restriction, the JES can be configured to output LU 1 data
  256.       streams, and the CICS can be  configured for LU 3 data streams.
  257.       Therefore, the server will identify what LU type the current
  258.       application connected to the server is using.  If that type is LU
  259.       1, ALL message records sent to the Client will be preceded by one
  260.       byte of binary zeros (0x00).  If the first byte is not zeros,
  261.       then that byte will be a valid LU type 3 Write-Command-Code(WCC),
  262.       which can NEVER be zeros.  Thus, the client can tell the LU type
  263.       of data as each record is received.
  264.  
  265.       This protocol does allow for the client to shutdown if the client
  266.       does not wish to support both LU types.  This is accomplished by
  267.       detecting an invalid data type from the received record, and
  268.       notifying the user that the mainframe application has sent LU
  269.       type x print data and should be configured for LU type y
  270.       printing.
  271.  
  272.       4.  COMMAND STRUCTURE
  273.  
  274.       1. All TELNET commands consist of at least a two-byte sequence:
  275.       the "Interpret-as-Command(IAC)" escape character followed by the
  276.       code for the command.
  277.  
  278.       NOTE:  Since the TELNET IAC character (255 decimal) is used as a
  279.       delimiter (together with EOR) in the inbound and outbound data
  280.       streams, a data byte within the data stream itself that has the
  281.       same value as the IAC command is sent as two bytes (255, 255) and
  282.       one byte is discarded.
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290. C. Graves                Expires January 1994                 [Page 5]
  291.  
  292.  
  293. Internet Draft           TN3270 Extensions                   July 1993
  294.  
  295.  
  296.       4.1  TELNET COMMANDS
  297.  
  298.       Command meaning-  WILL and DO commands are used to obtain and
  299.       grant permission for the subsequent subnegotiation.  Both sides
  300.       must exchange WILL TERM-TYPE and DO TERM-TYPE before
  301.       subnegotiation.
  302.  
  303.  
  304.  
  305.       The actual exchange of information is done within the option
  306.       subcommand.
  307.  
  308.       <IAC DO TERMINAL-TYPE>  Sender requests that the other party
  309.       begin terminal-type sub-negotiation.
  310.  
  311.       <IAC WILL TERMINAL-TYPE>  Sender is willing to send terminal-type
  312.       information in a subsequent sub-negotiation.
  313.  
  314.       <IAC SB TERMINAL-TYPE SEND IAC SE>  Sender requests the receiver
  315.       to transmit his terminal-type.
  316.  
  317.       <IAC SB TERM TYPE IS IBM-3287-1 IAC SE>   Sender is stating the
  318.       name of his terminal-type.  The code for <IS> is 0.  Optionally,
  319.       a specific Logical Unit (LU) can be requested by using the
  320.       TERMINAL-TYPE string below.   If no LUname is specified, the
  321.       first available 3287 LU is selected.
  322.  
  323.                      IAC SB TERM-TYPE IS IBM-3287-1 @ LUNAME IAC SE
  324.  
  325.       <IAC DO BINARY>  Sender requests that sender of the data starts
  326.       transmitting or confirms that the sender of data is expected to
  327.       transmit characters that are to be interpreted as 8 bits of
  328.       binary data by the receiver.
  329.  
  330.       <IAC WILL BINARY>   Sender requests permission to begin
  331.       transmitting, or confirms it will now begin transmitting binary
  332.       data.
  333.  
  334.       An <EOR> is sent at the end of each SNA Request Unit (RU) end of
  335.       chain, in either direction.   The first byte following the <EOR>
  336.       is a Write-Command-Code(WCC) for LU 3 data streams.
  337.  
  338.       An <AO> is sent at the end of the SNA RU and end of bracket.
  339.       This signifies the end of the print output or file by the IBM
  340.       host application and possibly a change of LU type.
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348. C. Graves                Expires January 1994                 [Page 6]
  349.  
  350.  
  351. Internet Draft           TN3270 Extensions                   July 1993
  352.  
  353.  
  354.       4.2   COMMAND VALUES
  355.  
  356.  
  357.                      TELNET COMMAND                     CODE
  358.                      IAC- Interpret as Command           255
  359.                      DO                                  253
  360.                      WILL                                251
  361.                      SB- SuBnegotiation option           250
  362.                      SE- Subnegotiation End              240
  363.                      TERMINAL-TYPE                        24
  364.                      SEND                                  1
  365.                      IS                                    0
  366.                      EOR- End-Of-Record                   25
  367.                      BINARY                                0
  368.                      AO- Abort Output                    245
  369.                      IP- Interrupt Process               244
  370.                      AYT- Are You There                  246
  371.                      BREAK                               243
  372.  
  373.  
  374.  
  375.       NOTE:  The above codes and code sequences have the indicated
  376.       meaning only when immediately preceded by an "Interpret as
  377.       Command (IAC)".
  378.  
  379.  
  380.       5.  TN3270 Printer Status Message- The status message can be sent
  381.       at any time.  It must be sent every time the TN3270 Server sends
  382.       an End-of-Record(EOR) indicator to the TN3270 Client, or when a
  383.       printing error occurs at the Client.  The Printer Status Message
  384.       is only sent by the TN3270 Client. Once the End-Of-Record IAC is
  385.       processed, the TN3270 Client sends the status message to the
  386.       server when it is ready to receive more print data.
  387.  
  388.  
  389.       MESSAGE DESCRIPTION:      SOH  %  R  S1  S2  IAC  EOR
  390.  
  391.  
  392.                                SOH = 0X01
  393.                                % = 0X6C
  394.                                R = 0XD9
  395.                                S1 = Status/Sense Byte 0
  396.                                S2 = Status/Sense Byte 1
  397.                                IAC = Telnet IAC Character
  398.                                EOR = Telnet EOR Character
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406. C. Graves                Expires January 1994                 [Page 7]
  407.  
  408.  
  409. Internet Draft           TN3270 Extensions                   July 1993
  410.  
  411.  
  412.       5.1   Status/Sense Byte description
  413.  
  414.  
  415.       5.1.1.         S/S Byte 0:
  416.  
  417.  
  418.         High Order                                          Low Order
  419.  
  420.  
  421.         _____________________________________________________________
  422.         |                                                           |
  423.         |   0      1      2      3      4      5      6      7      |
  424.         |___________________________________________________________|
  425.  
  426.  
  427.           Bit Number:       Bit Definition:
  428.  
  429.                 0           Always Zero
  430.  
  431.                 1           Always Zero
  432.  
  433.                 2           Always Zero
  434.  
  435.                 3           Always Zero
  436.  
  437.                 4           Always Zero
  438.  
  439.                 5           Unit Specify- is set due to an error
  440.                            condition.  The reason for the error
  441.                            condition will be indicated in S/S Byte 1.
  442.                            See Note 1*.
  443.  
  444.                 6          Device End- when this bit sent in response
  445.                            to a data message it indicates the client
  446.                            has successfully processed the data message
  447.                            from the server and notifies the server to
  448.                            send a new data message to the client when
  449.                            available.   See Note 2*.
  450.  
  451.                 7           Always Zero
  452.  
  453.  
  454.       Note 1*:   A negative response to the Server's data message would
  455.       be S/S Byte 0 Bit 5 "Unit Specify condition".  The possible Unit
  456.       Specify conditions are listed below.  (See Section 3.2 for bit
  457.       settings for the Unit Specify conditions listed below)
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464. C. Graves                Expires January 1994                 [Page 8]
  465.  
  466.  
  467. Internet Draft           TN3270 Extensions                   July 1993
  468.  
  469.  
  470.                 Unit Specify Condition:    SNA Sense Code sent to host:
  471.  
  472.                 Command Rejected                     0X10030000
  473.                 Intervention Required                0X08020000
  474.                 Data Check                           0X10010000
  475.                 Operation Check                      0X10050000
  476.                 Component Disconnected (LU)          0X08020000
  477.  
  478.        Note 2*:   Device End-  A positive response to the Server's data
  479.       message would be the "Device End" bit (S/S Byte 0 Bit 6) to
  480.       indicate a ready to receive data from the host condition.  This
  481.       will also be sent after clearing a previous Unit Specify
  482.       condition of "Intervention Required".
  483.  
  484.  
  485.       5.1.2.         S/S Byte 1:
  486.  
  487.  
  488.          High Order                                           Low Order
  489.  
  490.        ______________________________________________________________
  491.        |                                                            |
  492.        |    0      1      2      3      4      5      6      7      |
  493.        |____________________________________________________________|
  494.  
  495.  
  496.           Bit Number:       Bit Definition:
  497.  
  498.  
  499.                0            Always Zero
  500.  
  501.                1            Always Zero
  502.  
  503.                2            Command Rejected (CR) -- This bit
  504.                            indicates an invalid 3270 command
  505.                            generated.
  506.  
  507.                3            Intervention Required- Printer Not Ready.
  508.                            See Note 3*.
  509.  
  510.                4            Component Disconnected- Printer is powered
  511.                            off or printer cable not connected.  See
  512.                            Note 4*.
  513.  
  514.                5            Data Check- Invalid print data
  515.  
  516.                6            Always Zero
  517.  
  518.                7            Operation Check- An illegal buffer address
  519.                            or incomplete order sequence
  520.  
  521.  
  522. C. Graves                Expires January 1994                 [Page 9]
  523.  
  524.  
  525. Internet Draft           TN3270 Extensions                   July 1993
  526.  
  527.  
  528.       Note 3*:  The Intervention Required is cleared by sending an S/S
  529.       message with the "Device End" bit (Bit 6 of S/S byte  0).  The
  530.       LUSTAT sent to the host is 0X00010000.  The IBM host interprets
  531.       this as a "printer now ready" condition.
  532.  
  533.       Note 4*:  The Component disconnected is cleared by sending an S/S
  534.       message with the "Device End" bit  (Bit 6 of S/S byte 0).  The
  535.       LUSTAT sent to the host is 0X082B0000.  The IBM host interprets
  536.       this as a "printer now ready -- presentation space integrity may
  537.       be lost" condition
  538.  
  539.  
  540.       6.  The following is an example of the Client-Server negotiation
  541.       process.
  542.  
  543.       Server:   IAC DO TERMINAL-TYPE
  544.       Client:        IAC WILL TERMINAL-TYPE
  545.       Server:   IAC SB TERMINAL-TYPE SEND IAC SE
  546.       Client:        IAC SB TERMINAL-TYPE IS IBM-3287-1 IAC SE
  547.  
  548.       Note: To request a specific LU the TERMINAL-TYPE string would be:
  549.       IAC SB TERMINAL-TYPE IS IBM-3287-1 @ LUNAME IAC SE
  550.       (The client has specified its terminal type is an IBM-3287-1)
  551.  
  552.  
  553.       Server:   IAC DO END-OF-RECORD
  554.       Client:        IAC WILL END-OF-RECORD
  555.       Server:   IAC WILL END-OF-RECORD
  556.       Client:        IAC DO END-OF-RECORD
  557.  
  558.       (The Server and Client have both agreed to transmit End-Of-Record
  559.       (EOR)).
  560.  
  561.  
  562.       Server:   IAC DO TRANSMIT-BINARY
  563.       Client:        IAC WILL TRANSMIT-BINARY
  564.       Server:   IAC WILL TRANSMIT-BINARY
  565.       Client:        IAC DO TRANSMIT-BINARY
  566.       (The Server and Client have both agreed to use binary
  567.       transmission)
  568.  
  569.  
  570.       Server:   0x00 (3270 PRINT DATA)
  571.       Client:        (S/S with DEV END) IAC EOR
  572.       Server:   0x00 (3270 PRINT DATA) IAC EOR
  573.  
  574.       NOTE:  LU 1 type data is prefaced with a 0x00 character. LU 3
  575.       type data is not prefaced with a special character.  This
  576.       character will precede print data in each chain, and should be
  577.       discarded before the print data is processed.   An <IAC EOR> must
  578.       be received before changing to LU 1 or LU 3 type data.
  579.  
  580. C. Graves                Expires January 1994                 [Page 10]
  581.  
  582.  
  583. Internet Draft           TN3270 Extensions                   July 1993
  584.  
  585.  
  586.  
  587.  
  588.  
  589.       Client:        (S/S with IR) IAC EOR (This indicates a paper jam
  590.                     at printer.)
  591.       Client:        (S/S with DE) IAC EOR (This indicates the clearing
  592.                     of above condition.)
  593.       Server:  0x00 (3270 PRINT DATA) (This indicates start of LU 1
  594.                data)
  595.  
  596.       Server:   (3270 PRINT DATA)
  597.       Server:   (3270 PRINT DATA)
  598.       Server:   (3270 PRINT DATA) IAC EOR
  599.       Client:        (S/S with DE) IAC EOR
  600.       Server:   0x00 (LAST 3270 PRINT DATA) IAC EOR
  601.  
  602.  
  603.       Client:        (S/S with DE) IAC EOR
  604.       Server:   IAC AO
  605.       (The Abort Output <AO> signifies the end-of-bracket -- end of
  606.       print job)
  607.  
  608.  
  609.  
  610.       7.  SECURITY
  611.  
  612.       This document does not specify a security methodology to insure
  613.       that the client requesting a printer LU name is authorized to
  614.       access that LU.  Currently, this is left up to individual server
  615.       implementations.  The design of the protocols described in this
  616.       document allow for the future incorporation of the RFCs regarding
  617.       encryptions and authentication protocols and services.  However,
  618.       before this may occur, certain extensions may be required to the
  619.       protocols defined in this document or to the encryptions and
  620.       authentication services and protocols.
  621.  
  622.       If a client requests a printer LU name that is currently in use,
  623.       the server should respond with an NVT string of:
  624.  
  625.       Requested LU currently in use
  626.  
  627.       Optionally, the server may include the IP address of the device
  628.       currently using the requested LU name.
  629.  
  630.       The server will then terminate the connection with the client.
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638. C. Graves                Expires January 1994                 [Page 11]
  639.  
  640.  
  641. Internet Draft           TN3270 Extensions                   July 1993
  642.  
  643.  
  644.       8. REFERENCES
  645.  
  646.  
  647.       [1]   J. Postel  and  J. Reynolds,  "TELNET Protocol
  648.              specification", RFC 854, USC/ Information Services
  649.              Institute, May 1983
  650.  
  651.       [2]   J. VanBokkeln,  "TELNET Terminal-Type Option" RFC 1091, FTP
  652.              Software Inc., February 1989.
  653.  
  654.       [3]   J. Postel and J. Reynolds, "TELNET Binary Transmission",
  655.              RFC 856, USC/Information Services Institute, May 1983.
  656.  
  657.  
  658.  
  659.       Author's Address:
  660.  
  661.  
  662.       Cleve Graves             cvg@oc.com
  663.       Michelle Angel           angel@oc.com
  664.  
  665.       2711 LBJ Freeway
  666.       Dallas, Texas  75234
  667.       Phone: (214) 484-5200
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696. C. Graves                Expires January 1994                 [Page 12]
  697.  
  698.  
  699.